Hi @mroeschke & @datapythonista ,

Going through the details in Code Checks / pre-commit (pull_request), it seems there is a trailing whitespace in my code that is causing the issue. There is an extra whitespace at line 59 in team.md (Please ref. screenshot below). I am making the change and commiting again in the same PR.

Ref.

@github-actions pre-commit

Okay,

So the Code Checks / pre-commit (pull_request) is passing now.
But I am not sure why Ubuntu / Data Manager (pull_request) action is now failing for this PR. I have gone through the action details/summary and and it seems there is an AssertionError in this function/code-block of pandas/util/_test_decorators.py :

But as per my understanding, this should run if the platform is Windows (line 250), so why is it being executed in an Ubuntu based check ? Maybe there is some gap in my understanding, please clarify & let me know the way forward.

Thanks

Preview docs at: https://pandas.pydata.org/preview/51266/

Thanks @Kabiirk, this seems to be working as expected: https://pandas.pydata.org/preview/51266/about/team.html and the CI failures seem unrelated to this PR.

I'd personally avoid having the real addresses in the html as said in the issue. I think this is an improvement, but with the approach I proposed we could avoid scrappers using a regex for the email addresses, not only the ones that extract it from the a tag analyzing the dom.

@datapythonista Per my understanding, you wanted to prepend text to the email initially, then have a JS script change that text.

Not sure how the initial prepending of text would work though, since prepending & removing text with the same JS script would have no effect because the original email would still populate the DOM first, then be worked upon (prepend + removal). For this let me see if I can do anything with Event Listeners or defer/onLoad property in JS to make sure template loads the wrong email first, then JS script runs after that and changes it.

Alternatively, emails from the source itself would need to have a prefix, which the JS script removes (I don't think that's a good Idea).

I'll make changes in this PR itself.

Alternatively, emails from the source itself would need to have a prefix, which the JS script removes (I don't think that's a good Idea).

Not in the source (the config file), but in the template, literally in the same line where you remove the prefix again via javascript. It's not great to have to do this, but I think it's a much simpler approach than any alternative that prevents the email addresses to be in the html, while they are made available to users.

Thanks @Kabiirk

Hi @datapythonista,

I have implemented the proposed change. As expected, scraper picks up the wrong email (i.e. with the prefix):

While the correct email is visible to the end-user after the<script></script> tag executes:

Moreover, I was able to completely eliminate the use of workgroup.contact from the <script></script> tags. So even if someone takes a raw dump of the HTML response with requests.get(TEAM_URL).content.decode(), they will not get the email from within the<script></script>. At least not without manual effort.

I'll make the suggested changes in my local branch & commit again.

Hi,

I tested this and it works, have committed the same to PR. Let me know the way forward.

Hi @datapythonista ,

Following up on your approval, let me know if this PR is supposed to be merged by me, or it would be merged by you ?

Sorry for the delay @Kabiirk. We usually want two core developers to review a PR before it gets merged, to be in the safe side. I think we're both done here, let's see if another core dev can do the second review soon, and when they do, they'll merge. Thanks again for the help with this!

Thanks @Kabiirk

Thanks a lot @datapythonista & @mroeschke

No worries, thanks for clarifying that.
I understand it can be a challenge to comprehensively look at so many PRs & give in-depth inputs ! Really appreciate your help & suggestions on this PR.